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AGENDA FOR EXAMtNSR INTERVIiW FOR S/N 1 0/?58,574 



ThefoHowmg amendments and argumenb are what I propose presenting in ttie next step in the 
iwttsecutton. 



a) Proposed Ciaim Changes 



1 , :(p«>posed} A system for pontroSting ^ shared display, comprising: 

a gfen^-ai purpose computing device compn^irji , ^ , a disp la y <ji^vice: and 
a Qomputer program comprising program roodujes executaisi-fe the ddmputto^ 
device, comprising, 

a plurality of input mcxiuies each providing a different oommunicatiGn 
modiaif^, artd which coHecttveiy input infomiation from muittpie users, 

a iogic moduie comprising m appfcatfon runhing on the shsmd display 
whtcH based Oh the user-inputted information gener?te^ disptay ihsifuctiohs and data pertainihg 
to Ihe rurtrjirjg of said application, wherein said u ^^rMriputted Ipformation comprises at l^^st one 

a layout module which based on the display instructions and data from 
the logic module generates layout instructions and packages data for display, and 

a display moduie vsjhfch recieives t^^ 
tse layout module and employs the same to dispfay content in the shared disptey on the shared 
display device. 

27, {proposed) A computer-implemented process for controlling a shared dispiay on a 
display device , comprising using a computer to perfoma the foiiowing process actions: 

establish ing multiple input modalities to Input information frorn multiple users, 
wherein at least one of the input modaJities is characterfzed by a iateocy greater than about 1,0 
second , and wherein said usef-inputted lnfomiation comprises at least one of video data Or audio 
data Of document data ; and 

inputting the user Informaiion from «ie fnuj^le input modafities to a single 
computer program which employs the user infofroatiof* io control the content displayed on Jri the 
shared dtsotay on the display device . 

2B. (proposed) A system for contr<^}fng a shared display, comprising: 
a genera! purpose computing device; 
at least one display device shoysfing fiie shared display; and 
a computer program comprising program modules executable by the computing 
device, compris&ig, 

a plurality of input modules each pfpvidlfvg a diffierent input modality at 
least one of which is characterised by s iatency oKceeding about 1 secdhd, and Which collectively 
input information from muitipie users, wherein said user-inputted infomiation comprises at least 
one of Video data or audio data or document data. 

an application module which receives 8iie Mser ihfdrmatJon from the input 
modules and which based on the infomiafion generics display la^ouS instrucBons and packages 
data for display, and 

a display module whlc*i receives the liaydMi insfructforts and data from 
the application module and employs the information and data to display content oh in the shared 

display on the display device . 

35. (proposed) A computer-readable medium having eomputer-executable In^ructlons 
for controlling a shared display on a display device, said computer-executabie instructions 
comprising: 
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estabSishlng muittpie input modaiities to input informstton from multfpie users, 
wherein at feast one of the input modafities is characterized by a tatency greater than about 10 
second, and vtfherein said useF'ihPUtted irtfof mation comprfees at ieast one of video data or au dio 

inputting the user informatsdn frorn themultipfe input modaiities to a sirvgle 
ctsttputer program whicft ernptoys theusfe^-trifbrmation to confroJ the icontent display^ onJi the 
shared display Qf> the disptay devfce . 



b) The Sectio n 1 01 Rejection of Ciaim 2 7 

Claim 27 was rejected under 35 USC101 as being directed toward non-statutory subject matter. 
In essence, t»e Examiner contends tiat the elatms are directed toward what amounts to a 
computer program per «©, the appfscanit respecMy disagrees. 

The applicant is not eiaiming a computer program piarse as coritended m the <3}fiee Action. 
Genericaity, the preambie of fridependent Claim 27 reads: 

"A corhputer-implemented process for..., comprising using a computer to petfprm ttie 
foltowing process actions;** 

ThuSi the applicant Is daimtng a process impSemented on a computer where the of the 
jwpcess are performed uilhg the computer. This © statutory subject miatter. 

As stated in the MPBP {see Sec«on 210B.01 (1) at Page2tQO-10, Rev. e, September 2007); 

"Computer programs are often recited as part of a ciaim. USPTO personnei should 
detemilne whether th^ computer program is being t^aimed as part of an otherwise 
statutory manUfacturiB or machine, in such a case^ tie claim remains statutory 
irresp^tlye of the fact that a computer program is included in the ctaim. The ^^r ^ e resutt 
occurs when a computer program fs used in a comgutertee(ij propes$ whcre^ t^^^ 
cofflfiii^er executes the Instructions set fortj^ In the^omp»ter prff^ram * {emphmis 
acftfed) 

eieariy, in the ease of Ciaim 27, the actions are being claimed as part of a statutory process- 
namely a process with actions tf^at are performed using a computer. Accord ingSy, given that 
Claim 27 is directed toward statutory subject mailer^ it is respectfulty requested that the re|eetion 
be recohsideredi 



c) Ttie Section 1Q3Ca^ Rejection of Ciaims 1-38 

Claims 1-38 were rejected under 35 USC 103(a) as being obvious over Ho et a!., U.S. Patent 
Application Pubiication No. 2005/0066284, in view of Salesky et a!., U.S. Patent t^o, 6,343.313. 
In response, the appiicants propose amending these clai.nis to make them patentabie over the 
cited combination. More particuiarly, independent Cfatms 1, 27, 28 and 35 wii! be amended to 
include a recitation of vrfiat kind of user-inputted information is input and used to display ositent 
onashareddispJay. 

The appiicants would claim; 

"a logic moduie comprising an apptfeation which based on the user-inputted 
inft»rmatfon generates display Snstructions and data, whereih said user-ihputted 
Irtformation eofftprlseis at least one of video data or audio data or document data, a 

layout modtite which based oh the display instf«ctions and data from the logic module 
generates layout lhstructior\s and packages data for display, and a display module which 
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feceiy«& the tayout Irtstruotlotis ami data from the tayctut module and employs the 
same to display content In the shared display on the display device" (see Ciaims 1- 
26); 

"establishing multfpfe input modatities to input Wormation from muitipte tisers, wherefn at 
least one of the input modalities is chafaeterfeed by a latency greater than abdut 1 .0 
second, and wheretn satd useNrtputted informatfors comprises at least one of video 
data or audio data or document data; and inputting the user infomiation from the 
multJpie input modaiilies to a single computer program which employs the user 
information to control the content displayed in the shared display on the display 
device" (see Claim 27) 

"a plurality of input modules each prnviding a different input modality at least one of which 
|s dtigtractedzed i?y a latency exceeding about 1 second, and which coilectlveSy input 
informatidrt from muftipfe users^.wh^fein siald user-Inputted snformatiort comprises at 
least one of video datta or atidld data or dociimemt data, an application module 
which receives the user information from the input modufes and which based on 
the infottnation generates display iayout InstrMCtions and pacitiat0es data for 
display, and a display modute wftfch receives the Ja)«>ut fe?structiGns and data from the 
application module arid employs the information and data to display content In th$ 
sifstred ttispiay on the display device" (See Claims 28^4) 

"estabiishing muitiple input modalities to input fftformation from multiple users, wherein at 
feast one of the input modalities is charact^ized by a latency greater than about 1-6 
second, and wherein said user-inputted information comprises at least one of video 
data or audio data or document data; and inputting the user infofiTjation from the 
multiple input modaSities to a single corriputer prcjgrism whi<^ employs the user 
information to control the content displayed In the shared display on the display 
device" (See Claims 35-38). 

The feature in the foregoing claims "wherein said user-inputted information comprises at least 
one of video data or audio data or document data" wiil be referred to in the foliowirtg argument as 
the input data fmlum. Tm feature in the foregoing claims where the inputted user frtfomiation Is 
used to control or display ttte content in the shared display on the display device will be refemed 
to in the following argument as the shared display feature. 

The Ho-Salesky combination does not teach either the claimed input data or the shared display 
features. The Examiner has Already stated in the Office Action that Ho does not teach a display 
module which receives layout instructions and data, and employs the same to display content in 
the shared display. Thus, Ho dofes hot teach »5e claimed shared disptay feature. IHo also lacks a 
teadhtng of me claimed input data feature as there is no iiientbn of user-inputted infofmatton 
being used to generate iayout iristrubtidns and data for a shared display »iat include at least one 
of video data or audio data or document data. Salesky also facks th«ese teachings. 

More parSculariy, SaSesicy describes a Shared display that is shovm on a display device and 
whose corttent comes aimpst exclusSveiyf mm prescj-ibed seictions of the display screens 
associated with one or more pi^senters. Thus. Salesky's shareddispiay is generated from 
inputted images. The only exceptions invoh^e coordlnates fdr generating and locating pointers 
assmJiated with certain participants, and cerfein commands (such as one to change tte coior 
map). None of these inputs involves vkled data or audio data or document data. 

Granted, the Examiner contended in the Office Action that Salesky did teach a user inputting 
video data, audio data and document data, which would then presumably used in generating the 
shared display. The applicants respeetfutly disagree. As to video and audio data, the Examiner 
in rejecting Ciaims 24 and 2S, indicated Salesky teaches their input via Fig. 88 and it description 
at Col. 23. lines 1-44. Howesver, the only inputs shown in that figure and description that might he 
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construed as video or audio are the replay inputs, More particularly, the cited section of Satesky 

reads; 

■'FIG. 8B ilkistrates a more complex conference server which handles the more general 
case. The server in the general case rnight rnaintatf j additional output and additional input 
queue components for Iransmitting information io other servers and for storage services, 
including caching, short-term storing, recording, and archiving, and for later pia^^ack. 
These purposes are distinguished as ft^lows: caching provides fast memory hardware 
support in improving the performance of the server; short-term storage provides backup 
and refresh capability for extremely stow or temporarily disconnected clients, for newly 
connected servers that may need tnfiormaticsi older than that normally held in the output 
queue, for quick-turnaround failure recovery, and for ofher short-term needs; confermce 
sessions are recorded v^en they are primarily intended for later viewing by users 
of system vtfho may or may not be partlcipattnig in the session; an archival 
session captures ail or part of a meeting as it occurs and Is intended for users who 
typically were conferees In that session and have a reason to review the session 
later. Uses of recorded sessions, especially when they incorporate synchronized voice, 
inciude !ive oniine training sessions that also serve for future offline training, technical 
and marketing demonstrations, and formal presentations that can be broadcast or 
accessed remotely at will. Archived sessions have uses other than review, including 
briefing absentees, capturing interactions involving or aiding technical support, evaluating 
sates personnel^ and the like. Of course, these rieeds and characterizations are rjot 
exclusive or exhaustive. 

Possible features and methods for storage handling wiB now be fisted. The ^phasis wKI 
be on recording and srchiving, but shorter term storage modes will share many of these 

characteristics. 

During any session, there can be multiple "storage server" queues, or "storage streams," 
saving output to one or more nr>edfa. These can be controHed by the server itself, by 
fecorder-like interfaces {similar to a video cassette recorder, or "VCR") at the clients, or 
by other interfaces operated by conferees. Each stream can be independently controiied, 
or one controller can control multiple storage streams. The storage facility can operate 
concurrently in an ongoing meeting to record a live conference, or it can be used by itself 
to capture a recording for later replay", (empftas/s acfeferf) 

As can be seen from the foregoing excerpt, the reptay inputs are used in non-conference situation 
to review a previously held eonfer€»ice. The replay data is not used to generate a shared display, 
only to show a previously created one, A person viewing a replayed conference cannot change 
the shared display by entering video or audio data 

In regard to document date, the Examiner in rejecting Claim 26, Indicated Saiesky teaches Its 
input at Col. 30, lines 15-62, This section of Salesky reads; 

"A potential conferee 17(a) has navigated his or her WWW browser to Web sen,'er 30(a), 
and has asked through the Web page presented io connect to the meeting (as described 
above in the discussion of FIG, 2). There may be alternative ways, indicated here as 
30(b),(c), to connect to the meeting, including direct access to the riiseting manager or its 
database 34 (caHed here "tvleeting DB"). The meeting manager uses this database to 
hold rnfomiatfon concerning the meeting {the database need not be on the same 
computer as the meeting manager). This information was created when the person who 
set up the meeting requested that the meeting be .s^cheduled. gave descriptive 
information for the meeting, specified the keys and privileges, and provided other 
administrative information. The datai^ase is reconflgurable and easily extensible to 
include many arid varied meeting attributes. It may be accessed by a programmirig 
interface. Potential new conferee cWmi 17(a) sends a request to join the meeting, 
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and then supplies the key for the meeting that the potentiai conferee has obtained 
previou$Iy. Potential client 17(a) may aJso send previously selected identification 
infomiation such as icon, gong, etc, and this may be storeci in Meeting DB or in some 
o^er sort of directory service. After the meeting manager has validated potentiai client 
17(a), it sends a message tfiat causes the client software to run on the potential ciient 
and then sends that client software the address information for the CSS. such as a URl 
and port number. At that time, the ciient software may also receive address informatior? 
for backup CSSs in case the connection to the meetirtg faiis and autottiatic or rrsanuai 
attempts to reconnect to the initial CSS fail as wet!. The client then connects to the 
meeting, and may pass to the CSS its identification information. 

A CSS ts created to supervise a ssngie meeting. The moniloring-fiitering-queueing 
structures and procedures of FiGS, 8,A,3 are performed by the CSS. so FIGS. 8A.B could 
be viewed as part of the internal working each CSS in FIGS. 1 1-22 {in the case of 
distributed server functions described sn FIGS, 90-F, only part of FIGS. 8A,S might be 
descriptive of a particuiar CSS), tndeec, tnere wii! be a version of FIG. 8A applying to 
each data stream the CSS handles as n^uSripoif ■! reai-tsme traffic from a presenter cfent. 
The structure of FIG. 8B shows schematically now ;i-iese and other multiple input and 
output data streams are processed. The CSS also handles other input from and output to 
clients, such as information about attendee and presenter clients that helps with flow 
control, commands or requests from clients, labeled pointer Icon positions, and other 
stream data and controt traffic". 

M can be seen in the foregoing excerpt, the only discussion of user inputs tnvoives a request to 
join. keys, potehtiaity identification infermation, request for attendee/presenter information, and so 
on. None of this is documentdate that is input to control or tfisplay content In the ^aretJ dispiay, 

in further regard to Claim 16, the applicants claim, "the application associated with the logic 
module comprising one of (i) a computer game, {u} an electronic buiietih board, {iii) a 
voting/poHing tooK (iv) a web browsing tooi, {v) a computer graphics program or (vi) a lottery too!". 
The Examiner contends In the Office Action that this is taught in Saiesky at Col 23, iines 1 -33. 
The section of Satesky feads;: 

TIG. 8B iliustrates a mt«-e complex cwifference serv®* wfiteh handles the more genera! 
case. The server in ftte general case might maintain additiwia! output and additional input 
queue components for transmitting tnformaSon to otb^ servers and for storage services, 
including caching, short-term storing, recording, and archiving, and for later playback. 
Ttiese purposes are distinguished as fottows: caching provides fast memory hardware 
support in improving tlie performance of the server; short-term storage provides backup 
and refresh capabiitty for extremely slow or temporariiy disconnected clients, for newly 
connected servers that may need ;nforn!3t.>on older than that normally held in the output 
queue, for quick-turnaround faiii.ire recovery, and for other short-term needs, conference 
sessions are recorded when they are pnr^ iar^iy intended for later viewing by users of the 
system who may or may not be participatiog in the session; an archival session captures 
aii or part of a meeting as it occur.s and iS intended for users who typicaiiy were conferees 
in that session and have a reason to revsew Ihe session later. Uses o? recorded sessions, 
especially when they incorporate synchronized voice, include live online training sessions 
that also serve for future oifiine training, teci^nica! and marketing demonstrations, and 
formal presentations that can be broadcast or accessed remotely at will, Arcl-iived 
sessions have uses other than revtew, inciuding briefing absentees, capturing 
interactions Involving or aiding technical support, evaiuatins sales personnel, and the like. 
Of course, these needs and characterisations are not exclusive or exhaustive. 

Possible features and methods for storage handling wiS! now i>e listed. The emphasis will 
be on recording and archiving, but shorter term storage modes wiil share many of these 
characteristics". 
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There is absoiuleiy nothing in the foregoing excerpt to suggest that the ciaimed logic module 
tnciudes a computer game, or an electronic bulletin board, or a voting/poHIng tcso!, or a web 
browsing too!, or a computer graphics program, or a tottery tool. 

in further regard to Ciaim 33, the appiicanis claim, "the application; mo«Jufe comprises a sub- 
rnodute for afchtvlrtg the sdentity of «aqb user requesting data, as well as when the Infomiatfpn 
was requested and what data w^s (jrovtded to fte us^. The Exarniner contesnds in tie Office 
Action that the reasons for rejaction thfe ciaim were discussed with respect to tt>e regectjon of 
Claims However, wttiie Claims 5-9 do involved data o these ciaims do not 

address Rte arcihfvstg of *U)0 identity of eac^ ttser requesting data, as well as when the 
information was requested and what data was provided to the user*. The cited Ho-Safesisy 
combinatioh also lacks any mention of this t;^ of afchiving. 



